home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jul 89 / W0063-Re More Dispatching-Jul89 < prev    next >
Encoding:
Text File  |  1989-07-18  |  3.3 KB  |  72 lines  |  [TEXT/GEOL]
  1. Item    5238380                         13-July-89        13:31
  2.  
  3. From:   ROSENSTEIN1                     Rosenstein, Larry
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. Sub:    re More Dispatching
  8.  
  9. Curtis,
  10.  
  11. I don't know what other optimizations the linker does.  The one you described
  12. could in fact be done.
  13.  
  14. The linker can in fact tell whether an instance of TAbstract is created.  To
  15. create an instance of TAbstract you need to refer to TAbstract's method table.
  16. If there is no such reference, then no instances of TAbstract are created.  (If
  17. there were no subclasses of TAbstract, then the linker would strip out the
  18. entire class.)
  19.  
  20. If every subclass of TAbstract overrides DoComputation and no instances of
  21. TAbstract are created, then TAbstract.DoComputation cannot be called through
  22. the method dispatcher.  The link could remove it from the method table.  At
  23. this point, there are no references to that code, and it would be stripped if
  24. there is no INHERITED DoComputation call.  This is true even if the method
  25. contained something useful.
  26.  
  27. (All calls of the form INHERITED xxxx result in direct JSRs to the appropriate
  28. method.  That's the semantics of INHERITED.)
  29.  
  30. Your suggestions are good ones.  C++ allows you to do both of the things you
  31. describe.  You can make the constructor protected, which means it can only be
  32. called from subclasses.  You can also define the implementation of a method
  33. with '= 0' to indicate that it has no implementation and must be overridden.
  34.  
  35. I think these are reasonable additions to the language.  An important part of
  36. an o-o language is the mechanisms it provides for describing the type structure
  37. in your program.  In this case, you want to tell users of TAbstract that
  38. instances of it cannot be created, and that DoComputation must be overridden.
  39. It is reasonable for a language to allow you to express those things.
  40.  
  41. Re: your question about AuxiliaryRoutine
  42.  
  43. If there is a subclass of TAbstract that doesn't override AuxiliaryRoutine,
  44. then it must still appear in the method tables, because instances of that class
  45. will inherit that method.  If all subclasses override it, then the situtation
  46. is the same as DoComputation above.
  47.  
  48. The last thing you mention is really an issue of inline expansion.  That is,
  49. should the compiler inline substitute one procedure body in place of calls to
  50. that procedure.  C++ allows you to advise the compiler when it should expand a
  51. call inline.  Other languages might do this automatically based on heuristics.
  52.  
  53. There is never any dispatching overhead for an INHERITED call.  The semantics
  54. of INHERITED guarantee that the compiler can know which method to call at
  55. compiler time.  Therefore, the only overhead is that of a procedure call with
  56. parameters.
  57.  
  58. As I said above, I really don't know what optimizations the compiler/linker do
  59. other than the one for monomorphic methods.  In theory, the linker can change
  60. any method call to a direct procedure call if it can figure out the right
  61. procedure.
  62.  
  63. For example, suppose x is declared as a TFoo and TFoo has no subclasses.  Then
  64. you can be guaranteed that x is in fact a TFoo object, and I think you can
  65. statically bind all method calls involving x.  Again, I don't know if the
  66. linker does this optimization, but it should be easy to try out some cases and
  67. see what the results are.
  68.  
  69. Larry
  70.  
  71.  
  72.